The telephone system and other multi-user data networks are facing a significant change from their usual hierarchical, tree-like architectures. An architecture gaining favor for metropolitan-area networks (MANs) and even local-area networks (LANs) is based on the distributed-queue, dual-bus (DQDB) protocol, described by Newman in "The QPSX Man," IEEE Communications Magazine, vol. 26, 1988, pp. 20-28. A DQDB network is specified in IEEE Standard 802.6, "Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN)," December, 1990.
As illustrated in FIG. 1, a DQDB network 8 includes a dual bus 10 of two anti-parallel, unidirectional communication lines 12 and 14 conveying data signals in opposite directions. A primary frame generator 16 at the head end of one communication line 12 generates frame synchronization upon that communication line 12 according to the frame format illustrated in FIG. 2. A slave frame generator 18 at the head end of the other communication line 14 is slaved to the primary frame generator 16 and generates similar frame synchronization on the other communication line 14. A number N of nodes 20 are arranged along the dual bus 10. Each node 20 receives data from read taps 22 from both communications lines 12 and 14 and can write data along the propagation direction of the communication line 12 or 14 through unidirectional write taps 24. The read taps 22 are arranged upstream from the corresponding write taps 24 to allow a node 20 to read all data on the communication lines 12 and 14 irrespective of what it is writing on them.
Each frame 30, as shown in FIG. 2, has an interval of 125 .mu.s to match similar frames in digital telephony. The frame 30 starts with a frame header 32 followed by a fixed number of slots each having 424 bits (53 bytes or octets) and ends with a footer 36, which for DS-3 contains two octets. Each slot 34 can be used for either isochronous or non-isochronous communication. In isochronous communication, overall system control, not illustrated here, assigns a particular slot 34 of each frame to one node 20 so that it can transmit data at a fixed rate. Isochronous channels are relatively easy to control, are compatible with the non-isochronous nature of the present invention, and will not be further discussed.
In non-isochronous communication, a node 20 assigns to itself an available empty slot 34 and fills it with a segment of a data packet. Each node 20 handles its own non-isochronous access to the slots 34 according to a distributed queuing protocol executed at each node 20. In a simple implementation, the DQDB protocol requires only two bits BUSY and REQ at the head of each slot 34 followed by data, specifically a segment 37 of a data packet. The slot 34 contains additional control bits not relevant to the invention, such as a bit indicating whether this slot 34 is reserved for isochronous access by a particular node.
The single-bit BUSY control field indicates whether the slot 34 is full and hence not available. The single-bit REQ control field passes information through the network about the number of upstream non-isochronous requests for a slot 34. Every active REQ field passing a node 20 indicates that an upstream node 20 has queued a packet segment for transmission. When a node 20 has a segment waiting for transmission on, for instance, the rightward communication line 12, it issues a single active REQ control bit on an otherwise empty REQ control-bit location in the first REQ-empty slot 34 propagating on the leftward communication line 14. That is, it transmits the active REQ bit in the reverse direction from the direction along which it wants to transmit the segment. Only one segment awaiting transmission is placed in the portion of the distributed queue within a single node 20.
Each node 20 keeps track of the number of segments queued downstream from itself along one communication line 12 or 14 in which it desires to transmit a data segment by detecting the successive active REQ bits as they pass in the reverse direction on the other communication line 14 or 12 and by incrementing a request counter RQ. The node 20 further decrements an RQ counter whenever an empty slot 34, i.e. non-BUSY, passes it in the forward direction because it can assume that one downstream-queued request is satisfied by the empty slot.
When a node 20 attempts to queue a segment into its single-segment local portion of the distributed queue, it does two things. It transmits one active REQ bit in the reverse direction, and it transfers the count in the request counter RQ to a second, countdown counter CD not shown. The node 20 decrements the countdown counter CD for each passing empty slot 34, which will be used by a downstream node 20 that is more senior to it in the distributed queue. When the countdown counter CD in a node 20 reaches zero, that node 20 can transmit its segment in the first empty slot.
The dual-bus network of FIG. 1 operating with the DQDB protocol exhibits low delay latency in lightly loaded conditions. In heavily loaded conditions, it exhibits fair access and high throughput and operates free of congestion. It is also highly reliable. The taps 22 and 24 do not need to channel all the data through the nodes 20 but merely read and selectively write to the communication lines 12 and 14. In practical electronic systems, however, the taps 22 and 24 regenerate passing signals and perform a minimal amount of switching. Nonetheless, if a node 20 fails, in most failure modes it simply drops out without affecting the rest of the network.
The network can be made into a near ring by physically wrapping the communication lines 12 and 14 into a ring geometry although the two frame generators 16 and 18 are effectively located at neighboring nodes. If selectively activatable frame generators are located at each node 20, when the dual bus 10 is accidentally severed at a location between two nodes 20, the ring can quickly reconfigure itself with the failed bus section excluded from the ring but with all nodes still connected to the reconfigured near ring.
The DQDB architecture can be effectively used with electrical transmission lines or with optical fibers. Indeed, it is important that the architecture used with electrical transmission lines be equally usable with optical fibers because the network is being progressively converted to the higher-capacity fibers. However, the DQDB architecture in fact cannot fully utilize the full advantages of optical fiber.
Silica optical fiber has a nearly unlimited optical bandwidth measured in many terabits per second (10.sup.12 bits/sec). In contrast, the speed of electronics is far below this level. Advanced fiber communication systems are being installed with electronics operating at 2.5 gigabits per second (2.5.times.10.sup.9 bits/sec). Advanced prototypes are being designed for operation at 10 gigabits per second. Such speeds are approaching fundamental limitations of the operation of silicon electronics. Much higher speeds seem infeasible over even the medium term. The DQDB architecture, however, is dependent upon a sizable portion of the node electronics operating at the speed of the communication lines.
Several suggestions have been made for dividing the bandwidth of silica fibers into several smaller channels of bandwidth commensurate with silicon electronics. Effectively, the communication lines 12 and 14 can then be considered as communication buses of multiple parallel lines or channels. As an example, wavelength-division multiplexing (WDM) uses multiple lasers operating at different optical carrier frequencies to simultaneously impress several different data signals on one optical fiber. At the receiving end, the optical signal is frequency filtered or divided, and the individual optical carriers are detected. Other examples that divide bandwidth include space-division multiplexing, sub-carrier multiplexing, and time-division multiplexing. However, DQDB suffers drawbacks with such an expanded bus of parallel channels since it must unambiguously track all upstream and downstream traffic to maintain its counters current.
In general, the distributed-queue, dual-bus architecture scales poorly with both increasing number of nodes and increasing bit rates. When a large number of nodes are connected to the dual bus, the average bandwidth per node becomes very small as a result of the multi-access nature of DQDB. An access bandwidth utilization factor (ABUF) is defined as the average available bandwidth per node at peak load divided by the peak access bandwidth. For a DQDB network with N nodes, ABUF.apprxeq.1/N. Hence, DQDB is not very effective for large N.